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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
T; Abstract 


The Internet Message Access Protocol [IMAP4] requires a client to 
poll the server for changes to the selected mailbox (new mail, 
deletions). It’s often more desirable to have the server transmit 
updates to the client in real time. This allows a user to see new 
mail immediately. It also helps some real-time applications based on 
IMAP, which might otherwise need to poll extremely often (such as 
every few seconds). (While the spec actually does allow a server to 
push EXISTS responses aysynchronously, a client can’t expect this 
behaviour and must poll.) 


This document specifies the syntax of an IDLE command, which will 
allow a client to tell the server that it’s ready to accept such 
real-time updates. 


2. Conventions Used in this Document 


In examples, "C:" and "S:" indicate lines sent by the client and 
server respectively. 


The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 
in this document are to be interpreted as described in RFC 2060 
[IMAP4]. 

3:3 Specification 
IDLE Command 


Arguments: none 


Responses: continuation data will be requested; the client sends 
the continuation data "DONE" to end the command 


Leiba Standards Track [Page 1] 


RFC 2177 IMAP4 IDLE command June 1997 


Result: OK - IDLE completed after client sent "DONE" 
NO - failure: the server will not allow the IDLE 
command at this time 
BAD - command unknown or arguments invalid 


The IDLE command may be used with any IMAP4 server implementation 
that returns "IDLE" as one of the supported capabilities to the 
CAPABILITY command. If the server does not advertise the IDLE 
capability, the client MUST NOT use the IDLE command and must poll 
for mailbox updates. In particular, the client MUST continue to be 
able to accept unsolicited untagged responses to ANY command, as 
specified in the base IMAP specification. 


The IDLE command is sent from the client to the server when the 
client is ready to accept unsolicited mailbox update messages. The 
server requests a response to the IDLE command using the continuation 
("+") response. The IDLE command remains active until the client 
responds to the continuation, and as long as an IDLE command is 
active, the server is now free to send untagged EXISTS, EXPUNGE, and 
other messages at any time. 


The IDLE command is terminated by the receipt of a "DONE" 
continuation from the client; such response satisfies the server’s 
continuation request. At that point, the server MAY send any 
remaining queued untagged responses and then MUST immediately send 
the tagged response to the IDLE command and prepare to process other 
commands. As in the base specification, the processing of any new 
command may cause the sending of unsolicited untagged responses, 
subject to the ambiguity limitations. The client MUST NOT send a 
command while the server is waiting for the DONE, since the server 
will not be able to distinguish a command from a continuation. 


The server MAY consider a client inactive if it has an IDLE command 
running, and if such a server has an inactivity timeout it MAY log 
the client off implicitly at the end of its timeout period. Because 
of that, clients using IDLE are advised to terminate the IDLE and 
re-issue it at least every 29 minutes to avoid being logged off. 
This still allows a client to receive immediate mailbox updates even 
though it need only "poll" at half hour intervals. 
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Example: 


4. Formal Syntax 


Ne 


na 


nNWNs 


NANNNNNA 


NANNANNAs 


ANNANANs 


IMAP4 IDLE command June 1997 


A001 SELECT INBOX 

* FLAGS (Deleted Seen) 

* 3 EXISTS 

* 0 RECENT 

* OK [UIDVALIDITY 1] 
A001 OK SELECT completed 
A002 IDLE 

+ idling 


-time passes; new mail arrives... 


* 4 EXISTS 
DONE 
A002 OK IDLE terminated 


-another client expunges message 2 now... 


A003 FETCH 4 ALL 

K-A RET CH, Costs) 

A003 OK FETCH completed 
A004 IDLE 

* 2 EXPUNGE 

* 3 EXISTS 

+ idling 


.time passes; another client expunges message 3... 


* 3 EXPUNGE 
* 2 EXISTS 


-time passes; new mail arrives... 


* 3 EXISTS 
DONE 
A004 OK IDLE terminated 


A005 FETCH 3 ALL 

* 3 FETCH (...) 

A005 OK FETCH completed 
A006 IDLE 


The following syntax specification uses the augmented Backus-Naur 
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 
Non-terminals referenced but not defined below are as defined by 


[IMAP4]. 


command_auth 


idle 


Leiba 


::= append / create / delete / examine / list / lsub / 
rename / select / status / subscribe / unsubscribe 
/ idle 
7; Valid only in Authenticated or Selected state 


:= "IDLE" CRLF "DONE" 
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6. Security Considerations 

There are no known security issues with this extension. 
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